telephone ("mobile") is increasingly becoming a universal communication and 
information instrument and is also increasingly being used to access goods and 
services. 

The dynamic development of mobile telecommunications has been 
5 significantly assisted in the last two to three years by the provision of tariffs on the 
basis of a prepaid credit (specifically, in the form of "prepaid cards"). These tariffs are 
found to be attractive in particular, due to their having no basic charge irrespective of 
use, their providing the user with a good cost control capability and their imposing no 
contractual obligation. For many users wanting to use newly appearing terminals 

10 immediately, this contractual obligation is also a decisive drawback in view of the 
extremely dynamic development of technology and tariffs in this area. Prepaid credits 
appeal especially to those young and dynamic users who, on the other hand, still have 
relatively low incomes. 

There are various methods for recharging prepaid credits which have also 

15 become established in practice. Besides purchasing a voucher, these include paying 
top-up sums by credit card, transfer instruction, direct debit or standing order. These 
payment methods are established and are familiar to the great majority of users. 
However, they are largely based on stable bank accounts and, in turn, assume a certain 
creditworthiness. As such, significant advantages of the prepaid method are lost again 

20 for certain user groups at this point. Some of these payment methods also involve 
onerous, relatively long-lasting commitment of the customer to a particular, 
formalized mode of payment and can be changed only with a relatively high level of 
complexity. 

The present invention is, therefore, directed toward providing an improved data 
25 transfer method and an improved system of the type specified above which can be 
used to top up a prepaid account flexibly as required in a simple and, nevertheless, 
reliable way. 

SUMMARY OF THE INVENTION 
The present invention encompasses the fundamental concept of using an 
30 "electronic wallet" (eWallet) to top up a prepaid credit; i.e., an electronic settlement 
account which is set up in a data network and can be electronically connected directly 
to the prepaid account. It also encompasses the concept of designing this settlement 
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account, which is also referred to below as eWallet account, such that it can be 
"controlled" from a terminal associated with the holder of the prepaid credit (or with a 
third party), so that topping-up of the prepaid credit can be controlled from the 
terminal in real time. 

5 The proposed method thus follows existing payment methods from the B2C 

(Business-to-Consumer) sector for paying for goods and services ordered over the 
Internet. In this context, an account management server on which the settlement 
account is managed, also referred to below as eWallet server, acts as a purchaser or a 
sender of the appropriate sum of money. Another server, on which the prepaid credit 

10 is managed, also referred to below as prepaid server, performs the function of the 
vendor or receiver of money. In a way, the payment option provided by the prepaid 
credit represents the "goods" (for example, for telecommunication services). 

Although a prepaid credit normally will be topped up by the holder 
himself/herself, that is to say from a settlement account associated with the holder of 

15 the prepaid credit, the proposed solution is not limited to this. Instead, it also includes 
topping up the prepaid account from an external eWallet account. Normally, this 

^ account is then not accessed by the holder of the prepaid account, of course, but in fact 
by the holder of the eWallet account in order to start the transfer. 

The proposed solution makes it possible to top up the prepaid account in real 

20 time; i.e., with immediate effect both for the holder and user and for the operator of the 
prepaid account. The electronic money is available to the operator immediately, so 
that the latter does not need to make any advance concession. On the other hand, the 
holder also need not make any advance concession without having the prepaid credit 
available immediately in return (as in the case of a direct debit payment, for example). 

25 The proposed solution can be implemented as an independent service and can 

be offered as such to the users of the prepaid credit and runs on a specific application 
server. The latter is also referred to below as a recharge server in view of the specific 
function. The recharge server also performs the connection and checking operations 
crucial for performing the top-up operation. A crucial function in this context is the 

30 checking of authentication and/or account data which are transferred by the user 
performing the top-up when the transaction is initiated. This check is made on the 
basis of comparison data stored, in the network or in the prepaid memory. 
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As a fundamental connection, the recharge server sets up a connection to the 
prepaid server in order to ascertain the presence of the prepaid credit to be topped up 
and the level of this credit. In addition, a connection is set up to the (at least one) 
eWallet server on which the settlement accounts are managed, in order to use this 
5 connection to perform the data transfer producing the electronic transfer operation. 

Finally, the recharge server maintains the telecommunication and data link set 
up by the terminal of the user initiating the top-up operation for the purposes of data 
entry under menu guidance, until a completion acknowledgement is transmitted. 
Optionally, the recharge server also sets up a connection to a terminal associated with 
10 the holder of the prepaid credit (if he/she is not identical to the user initiating the top- 
up). In this context, the recharge server also runs the software for controlling 
communication with the respective terminals; in particular, under visual or audible 
menu guidance. 

The explanations above also reveal the fundamental functional components of 
.15 a system suitable for implementing the method of the present invention, such that there 
V is no need to describe the system aspects of the present invention in detail again at this 
point. In particular, it is evident that, besides the fundamental network infrastructure 
(in particular, a combined data and telecommunication network) it is necessary to have 
servers on which the prepaid credit and the settlement accounts and the application 
20 software are managed, and the user needs to have a terminal for producing the 
transaction and for entering the relevant data. 

Additional features and advantages of the present invention are described in, 
and will be apparent from, the following Detailed Description of the Invention and the 
Figures. 

25 BRIEF DESCRIPTION OF THE FIGURES 

Figure 1 shows the block diagram schematic of the system to which the method 
of the present invention is applied. 

DETAILED DESCRIPTION OF THE INVENTION 
A preferred embodiment is described in detail with reference to Figure 1, the 
30 individual steps being symbolized in Figure 1 by circles containing numerals. In 
contrast to the use of language above, in this case the user is referred to as the 
"sender". A combined telecommunication and data network is simply referred to as 



4 




"NETWORK" in this case. The settlement account of the user (sender) is referred to 
as the "electric wallet of the sender". The other names are in line with the 
explanations of terms given further above. In the example, it is assumed that the 
sender and the receiver are not identical; that is to say that the electronic wallet of the 
5 sender is used to top up a prepaid credit of a different receiver. 
The sequence of the method is as follows: 

1. The sender uses his/her mobile radio terminal to set up a connection to the 
recharge server and authenticates himself/herself. As such, the settlement account of 
the sender is also clearly identifiable. 

10 2. The recharge server uses menu guidance displayed on the sender's terminal 
display or else conveyed in audible form to request the sender to fill in the recharge 
order. Specifically, for this purpose, the sender needs to specify at least the identity 
(e.g., MSISDN) of the receiver's prepaid account and the sum to be transferred. If the 
sender has a number of accounts on the eWallet server, he/she needs to specify the 

1 5 identity (account number) of the eWallet required. 

3. The recharge server checks with the eWallet server to determine whether the 
specified eWallet account of the service user exists and whether the specified amount 
is available in the account. 

4. If this is the case, the sum is reserved (blocked). 

20 5. The recharge server checks with the prepaid server to determine whether the 
specified prepaid account exists and whether the specified sum can be credited to the 
account. 

6. If this is the case, the reserved sum is transferred from the eWallet account of 
the service user to a service operator account, which is likewise managed on the 

25 eWallet server, and at the same time the credit balance of the prepaid account is 
increased. This is done, in particular, by incrementing an appropriate counter. The 
money is transferred in real time. 

7. The sender receives an acknowledgement about the successful transfer of 
money. 

30 8. The receiver is optionally informed about receipt of the sum of money in his 
prepaid account. 
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